The present invention relates to a terminal for distinguishing between email recipients using a specific identifier and its method.
A standard communication protocol used to send email via the Internet is referred to as Simple Mail Transfer Protocol (SMTP).
In general, there are 3 steps in an SMTP mail transaction. The email transaction begins with a MAIL command providing identification to a sender, then at least one successive recipient (RCPT) command providing information to a recipient follows the MAIL command. Finally, an end indicator of mail data confirms the email transaction.
The respective above steps will be described in further detail below.
The first step in the procedure is the MAIL command. Once a transmission channel is established, SMTP transmits the MAIL command indicating an email sender. The MAIL command initiates a new mail transaction, and instructs an SMTP-receiver to reset all state tables and then buffers including any recipient or mail data. In addition, the MAIL command provides a reverse path that can be used to report errors. When the MAIL command is accepted, the SMTP-receiver returns a OK reply.
The second step in the procedure is an RCPT command. The RCPT command provides one forward-path that identifies one recipient. When the RCPT command is accepted, a receiver-SMTP returns an OK reply and stores the forward-path. When the recipient is not identified, the receiver-SMTP returns a failure reply. This second step may be repeated any number of times. The forward-path can contain at least one mailbox.
The forward-path consists of a list of hosts, which is optional, and a destination mailbox, which is required. The list of hosts indicates that it is a source route, and the email must be relayed to the next host in the list. When the receiver-SMTP does not implement the relay function, it may use the same reply as that for an unknown local user. When the email is relayed, a relay host must be removed from the start of the forward-path and located at the start of the reverse-path. When the email arrives at the final destination, the destination mailbox alone is contained in the forward-path, and the receiver inserts the email in the destination mailbox on the basis of host mail conventions.
The final step in the procedure is a DATA command. When the DATA command is accepted, the SMTP-receiver returns a intermediate reply and considers all succeeding lines as a message text. When the end of the text is received and stored, the SMTP-receiver transmits an OK reply. Since mail data is sent on a transmission channel, the end of mail data must be indicated so that the command and reply dialog can be resumed.
SMTP indicates the end of mail data by transmitting a line containing only a period. An end indicator of mail data also confirms the mail transaction and instructs the receiver-SMTP to process to store recipients and mail data. When the command is accepted, the receiver-SMTP returns a OK reply. When the mail transaction is incomplete (e.g., when there is no recipient) or when resources are not available, it is considered that the DATA command has failed.
When the receiver-SMTP accepts the message for either relay or final delivery, it inserts a time-stamp line at the beginning of the mail data. The time-stamp line indicates the identity of the host that sent the message, the identity of the host that received the message and inserted the time stamp, and the date and time that the message was received. The relayed messages have multiple time-stamp line. When the receiver-SMTP makes final delivery of the message, it inserts a return-path line at the beginning of the mail data. In general, final delivery means that a message is delivered to a destination user, but in some cases the message may be further processed and transmitted by another mail system. The return-path line preserves information in the reverse path from the MAIL command.
FIG. 1 illustrates a general process of transmitting an email. As shown, a sender Mail User Agent (MUA) 110 contacts a forward Mail Transfer Agent (MTA) 120 using SMTP (S101). Then, the forward MTA 120 connects a system call to a Transmission Control Protocol (TCP) Mail Delivery Agent (MDA) 130 (S102).
The TCP MDA 130 sends a contact content between the sender MUA 110 and the forward MTA 120 to a receiver MTA 140 using SMTP (S103). Then, the receiver MTA 140 connects the system call to a local MDA 150 (S104). When the call is established, the local MDA 150 creates and sends a mail to a mailbox 160 (S105). The mailbox receiving the mail connects the system call to a receiver MUA 170 (S106). Then, a user reads the mail using a Mail Retrieval Agent (MRA).
FIG. 2 illustrates a conventional header created when an email is transmitted using SMTP. As shown, when a user inputs mail recipients, a server creates a mail header on the basis of the input information. Here, SMTP uses an RCPT command to identify the respective email recipients. When there are several email recipients, SMTP specifies the recipients using the RCPT command several times.
It is assumed in FIG. 2 that a user wants to send email to recipients A and B at the same time. Here, A's email address is Samsung1@samsung.com, and B's email address is Samsung2@samsung.com.
When the user inputs the recipients of the email as A and B, SMTP creates a header having A and B as recipients. First of all, an RCPT command, specifying that A is a recipient, is generated and sent to A (S210). When receiving the RCPT command, A determines whether the email can be accepted. When the email can be accepted, A accepts the RCPT command and returns an OK reply in response to the command (S220). On the contrary, when the email cannot be accepted, A returns a rejection response.
Then, the RCPT command is sent to B, who is the other email recipient (S230), and a response to the RCPT command is received (S240). Here, steps 230 and 240 are performed in the same way as steps 210 and 220.
When receiving the responses from the recipients A and B, SMPT forwards a DATA command, thereby transmitting the email.
In mobile devices, traffic is an important concern because of the following reasons.
First, traffic is associated with billing. Unlike a network of desktops operating under a flat sum system, a mobile device is charged for network access time. Therefore, all packets exchanged for data transmission may be a burden on a user.
Second, traffic is associated with speed. Speed also can be an important concern in a wireless environment providing a lower speed than a wired environment.
Meanwhile, storage space also can be an important concern in mobile devices. Fundamentally, the storage space of a mobile device is much smaller than that of a desktop. Therefore, when unnecessary traffic is caused and occupies much of the storage space of the mobile device, a user may not store necessary files or delete stored files.
When a user of a mobile device wants to send the same mail to several users, he/she inputs users who will receive the mail in the recipient field of the mail. In this case, the mail is sent to all the users in the same format. In other words, the same text and attachment file are sent to all the recipients.
Therefore, a mail having no, attachment file must be newly created for a recipient to whom the text with no attachment file is needed to be sent, which may cause unnecessary traffic in the mobile device. Furthermore, in this case, the user may waste the storage space of the mobile device due to the newly created mail.
Currently, email is coming into the spotlight as the most promising communication means in mobile devices. However, in comparison with a desktop, a mobile device has drawbacks in traffic, storage space, etc., and thus an email environment must be optimized for a mobile environment.